Closes #94 (CRYPTO-5, BUG/correctness).

The defect

Chisel::file_size_bytes and Stats.file_size_bytes both did
page_count.saturating_mul(PAGE_SIZE as u64). But PageIo::page_count
returns stride-units, and an encrypted database is re-strided to
ENC_PAGE_SIZE (8232) at open — so both public accessors under-reported
every encrypted database's size by 0.49%, unbounded in absolute terms
(40 MB of error at one million pages).

open_existing already computes this correctly for its FileSizeMismatch
arithmetic and its comment names the exact hazard:

multiply by the CURRENT stride, not the hardcoded PAGE_SIZE … reporting
them as PAGE_SIZE bytes would understate an encrypted file's true size

The two public accessors just never got the same treatment.

The fix

Adds TransactionManager::file_stride() — an infallible in-memory read of
PageIo::stride(), mirroring how open_existing reaches it — and
multiplies by that at both call sites. Docs on Chisel::stats,
Chisel::file_size_bytes and Stats::file_size_bytes updated to say
page_count × stride and name both strides.

No behaviour change for plaintext databases: stride is PAGE_SIZE there.

Test

file_size_bytes_matches_stat_for_both_strides asserts both accessors
equal fs::metadata(path).len(), for a plaintext and an encrypted database,
after growing each past the superblock region.

Asserting against stat(2) rather than a computed constant is what makes
the test load-bearing: PAGE_SIZE arithmetic can only agree with stat in
the plaintext case. Counterfactual — reverting just the
file_size_bytes line to PAGE_SIZE:

assertion `left == right` failed: enc.db: file_size_bytes() disagrees with stat(2)
  left: 1081344
 right: 1086624

(132 pages × 8192 vs × 8232.) The plaintext arm guards the other direction.

Verification

cargo test 682 passing, cargo clippy --all-targets -- -D warnings clean,
cargo fmt --check clean.

First of a stacked series addressing #94–#103.